Create virtual track buffers in NVS using customer segments to maintain newly written data across a power loss

ABSTRACT

A method for storing customer data at a non-volatile storage (NVS) at a storage server. A track buffer is maintained for identifying first and second sets of segments that are allocated in the NVS. A flag in the track buffer identifies which of the first and second sets of segments to use for storing customer data for which a write request has been made. The customer data is stored in the NVS in successive commit processes. Following a power loss in the storage server, the NVS uses the track buffer information to identify which of the first and second sets of segments was involved in the current commit process to allow the current commit process to be completed.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates generally to the field of data storage in computersystems and, more specifically, to managing the allocation ofnon-volatile storage resources in a storage server to prevent data lossdue to a power failure.

2. Description of the Related Art

Computer storage devices such as storage servers have high-capacity diskarrays to backup data from external host systems, such as host servers.For example, a large corporation or other enterprise may have a networkof servers that each store data for a number of workstations used byindividual employees. Periodically, the data on the host servers isbacked up to the high-capacity storage server to avoid data loss if thehost servers malfunction. A storage server may also backup data fromanother storage server, such as at a remote site. The storage serversare also known to employ redundant systems to provide additionalsafeguards against data loss. The IBM Enterprise Storage Server (ESS) isan example of a storage server.

A host system may send data to be backed up at a storage server via ahost adapter at the storage server. The data is then transferred fromthe host adapter to a volatile cache, and from the cache to anon-volatile storage (NVS). However, various difficulties arise inallocating resources in the NVS for accommodating the transfer of thedata in a manner that prevents data loss during a power failure.

BRIEF SUMMARY OF THE INVENTION

To overcome these and other deficiencies in the prior art, the presentinvention describes a method and system for allocating NVS resources ina storage server.

In a particular aspect of the invention, a method for storing customerdata at a non-volatile storage (NVS) at a storage server includesinitializing the NVS, prior to receiving a first write request at thestorage server for writing first customer data to the NVS, by allocatingfirst segments in the NVS for storing data, and, in response toreceiving the first write request, allocating second segments in the NVSfor storing additional data.

Related apparatuses and program storage devices are also provided.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, benefits and advantages of the presentinvention will become apparent by reference to the following text andfigures, with like reference numbers referring to like structures acrossthe views, wherein:

FIG. 1 illustrates an overview of a logical structure of a dual clusterstorage server;

FIG. 2 illustrates the storage of data in cache and non-volatilestorage;

FIG. 3 illustrates a write scenario involving a host adapter, cache andNVS;

FIG. 4 illustrates cache control blocks for tracks, and thecorresponding cache customer segments, which are seen by the hostadapters;

FIG. 5 illustrates track NVS control blocks and the corresponding trackbuffers seen by the host adapters;

FIG. 6 illustrates NVS control blocks for tracks, and the correspondingNVS customer segments, which are not seen by the host adapters;

FIG. 7 illustrates a cache control block data structure;

FIG. 8 illustrates an NVS control block data structure;

FIG. 9 illustrates track buffer control blocks and the correspondingvirtual track buffers, which are seen by the host adapters;

FIG. 10 illustrates a virtual track buffer data structure;

FIG. 11 illustrates an example of the virtual track buffer datastructure;

FIG. 12 illustrates the virtual track buffer of FIG. 11 after a firstwrite operation;

FIG. 13 illustrates a method for allocating segments for each virtualtrack buffer;

FIG. 14 illustrates a method for pre-allocating segments for a new writerequest; and

FIG. 15 illustrates a method for processing write requests following apower loss.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates an overview of a logical structure of a dual clusterstorage server. A storage server 100, which may an IBM EnterpriseStorage Server (ESS), for instance, is a high-capacity storage devicethat can back up data from a variety of different devices. For example,a large corporation or other enterprise may have a network of serversthat each store data for a number of workstations used by individualemployees. Periodically, the data on the host servers is backed up tothe high-capacity storage server 100 to avoid data loss if the hostservers malfunction. The storage server 100 can also provide datasharing between host servers since it is accessible to each host server.The storage server 100 itself has redundant storage resources to providean additional safeguard against data loss. As a further measure, thedata of the storage server 100 may be mirrored to another storageserver, typically at a remote site. A storage server of a particulartype, such as one that uses disk storage, may connect to one or moreother peer disk storage servers as well as to other storage devices,such as those using magnetic tape. Communication between the devices maybe achieved using any desired communication protocol and medium. A userinterface may be provided to allow a user to access informationregarding the status of the storage server 100.

The example storage server 100 includes two clusters for redundancy.Each cluster 105, 110, e.g., “cluster 0” and “cluster 1”, respectively,works independently, and may include cluster processor complexes 120,130 with processors 122, cache 124, 134, nonvolatile storage (NVS) 126,136, and device adapters 140, 150. The device adapters (DA) 140, 150 areused to connect the disks 160 to the caches 124, 134 in the clusterprocessor complexes 120, 130. In one possible design, each cluster 105,110 contains four device adapters 140, 150. Each adapter is part of apair, one on each cluster. A pair supports two independent paths to allof the disk drives served by the pair. Each disk array is configured tobe accessed by only one of the clusters. However, if a cluster failureoccurs, the surviving cluster automatically takes over all of the disks.The disk arrays or ranks 160 can be configured as RAID 5 (redundantarray of independent disks) or non-RAID arrays. Alternatively, anotherhigh-capacity storage medium may be used.

Processors 122 and 132 execute software, firmware and/or micro code,e.g., computer code devices, stored in an associated memory to achievethe functionality described herein. Such memories may be considered tobe program storage devices. The memories may be provided, e.g., in aregion of the respective cache that is preserved during a reboot, or ina separate non-volatile memory.

Host adapters (HAs) 170 are external interfaces that may support twoports, e.g., either small computer systems interface (SCSI) or IBM'senterprise systems connection (ESCON), which is an Enterprise SystemsArchitecture/390 and zSeries computer peripheral interface. This I/Ointerface uses ESA/390 logical protocols over a serial interface thatconfigures attached units to a communication fabric. For example, aremote storage server, host servers and a user interface may communicatewith the storage server 100 via the HAs. Fibre channel or fibre-channelconnection (FICON) has support for one channel per HA. Each HA connectsto both cluster processor complexes 120, 130 so that either cluster canhandle I/Os from any host adapter. A system adapter identificationnumber (SAID) is a unique identification number automatically assignedto each HA. The storage server 100 contains four host-adaptor bays, eachof which is connected to both clusters 105, 110 for redundancy.

FIG. 2 illustrates the storage of data in cache and non-volatile storageduring normal operations, e.g., with no power loss. In the clusterprocessor complex 120, the cache 124 stores read and write data forcluster 0. Write data refers to data that is to be written to the diskarrays 160 or other high-capacity storage medium. For example, this maybe data that is received from a host server via one of the host adapters170. This data is to be destaged or written to the disk arrays 160 as abackup measure. It is particularly important to safeguard the writedata, since it is modified data that cannot be recovered from the diskarrays 160. Read data refers to data that has been read from the diskarrays 160 or other high-capacity storage medium. For example, this maybe data that is to be communicated to a host server via one of the hostadapters in a scenario where the host server has lost its data due to afailure. It is acceptable for read data to be lost from cache since itcan be read again from the disk arrays. Read and write operations forthe cache 124 occur via the associated device adaptors 140. The NVS 126for the cluster processor complex 120 stores write data for clusterprocessor complex 130 as a backup to the data stored in the cache 134.

Analogously, in the cluster processor complex 130, the cache 134 storesread and write data for cluster 1 (110). The NVS 136 for the clusterprocessor complex 130 stores write data for the cluster processorcomplex 120 as a backup to the data stored in the cache 124. Read andwrite operations for the cache 134 occur via the associated deviceadaptors 150. Thus, the track data from the host adapter 171 is writtento the cache 124 of cluster 0 and the NVS 136 of cluster 1, or to thecache 134 of cluster 1 and the NVS 126 of cluster 0.

Generally, if data requested by a host resides in one of the caches 124,134, an immediate data transfer takes place. If the data is not in thecaches, one of the clusters sends a request to its device adapter toretrieve the data from the disk arrays 160. When a read operationarrives at a cluster, a cache hit occurs if the requested data residesin the cache, resulting in better performance. A cache miss occurs ifthe data is not in the cache. The I/O device is disconnected from thehost and a stage operation occurs, which involves reading data from adisk drive into the cache. The NVSs 126, 136, which are battery backedmemories, improve performance by allowing write I/O operations tocomplete after the data is stored in NVS, but before the data isdestaged to the disk arrays 160. If a cluster fails, the survivingcluster can access the write data of the failed cluster in its localNVS. The caches 124, 134 are volatile memories that are not batterybacked.

In one approach to a cached control storage server, the NVS memory inwhich the customer data was stored was provided on a card, and the sizeof the memory was larger than the PCI window space allowed to access theNVS card. Contiguous areas of memory called “track buffers” were used toallow the host adapter cards to write customer data into NVS. The NVScode would move the customer data using a hardware assist from the trackbuffer into the real customer segments once a communication such as amail message was received from the host adapter to “commit” the data.The customer segments could be allocated even after a power loss sincethe customer data was sitting in a track buffer that was saved acrossthe power loss. Since the NVS memory is allocated for customer trackuse, the allocation occurs on the Symmetric Multi-Processor (SMP), e.g.,processors 122 and 132, where the cache is, and the NVS is told whichsegments to use for the track. However, in a recent design, the NVSfunction is moved from adapter cards to the main processor complexmemory. Like the cache, the entire NVS memory can be mapped and seen bythe host adapters. The hardware assist functions no longer exist to movecustomer data from one location to another. Real track buffers are nolonger feasible since the main CPU processors would need to move thecustomer data from the track buffer to the real customer segments, butthis would significantly reduce performance.

In accordance with the invention, NVS customer segments arepre-allocated into “virtual track buffers” and are sent to the NVS 126,136. Before a virtual track buffer is allocated and used, a new set ofNVS segments are allocated and sent to the NVS to be used the next timethe virtual track buffer is used. The host adapter then writes thecustomer data into the virtual track buffer and sends a “commit” mailmessage to the NVS. The NVS maintains the virtual track buffer dataacross a power loss. If the commit processing occurs following a powerloss, the NVS can tell the SMP which segments were used for the committo enable the commit process to be completed for those segments.

In particular, before any host adapter 170 is allowed to write to theNVS 126, 136, virtual track buffers are allocated using real customersegments and sent to the NVS. These segments make up the first set ofsegments, termed “A” segments, that will be used for the first write toa track using a particular track buffer. This information is kept in anarea of the NVS that is maintained across a power loss. When a hostadapter wants to write a customer track into NVS, a new set of NVSsegment are allocated and attached to the cache track temporarily. Avirtual track buffer is then allocated for the transfer. The temporaryNVS segments are removed from the cache track, and are used to create aset of second segments, termed “B” segments, that will be used the nexttime the virtual track buffer is used. The “A” segments are thenattached to the cache track as the real NVS customer segments to use forthe track. The “B” segments are then sent to NVS in preparation for thenext write to the virtual track buffer. With this, the NVS knows thesegments used for a write before a write can occur, and NVS maintainsthe knowledge across a power loss. Information is maintained within NVSas to which segments, “A” or “B”, will be used for the write. Theinvention can be implemented using the data structures discussed herein.

FIG. 3 illustrates a write scenario involving a host adapter 171, cache124 and NVS 136. The following steps provide an overview of a possiblewrite scenario. Refer also to FIGS. 11 and 12. Steps preceded with “H”related to an action of the host adapter 171, while steps preceded with“N” relate to an action of the NVS 136, and steps preceded with “C”relate to an action of the cache 124. Not all messages or steps areshown.

H1. The host adapter gets a write request for a track from a host tostore the host's customer data.

H2. The host adapter sends mail to the cache with a track id to allocatecache/NVS segments and NVS track buffer. The track buffer is comprisedof a number of segments.

C3. In response to the mail from the host adapter, the cache allocatescache segments and creates a cache control block. Specifically, thecache allocates new NVS segments and attaches them to the cache controlblock. From FIG. 4, discussed further below, these would be segments 4and 5. Note that, during an initialization procedure, before any requestto store customer data is received at the cache from the host adapter,segments 0, 1 and 2, 3 were previously allocated. The Cache allocatesNVS Track Buffer 0, moves segments 4 and 5 from the control block to “B”segments, and moves “A” segments 0 and 1 to the cache control block.

C4. Cache sends mail to host adapter with NVS track buffer number 0 tostart the write.

C5. Cache builds and sends Track NVSCB control block and “B” segments toNVS to indicate the segments to use the next time track buffer 0 isused. The “Use A or B” indicator or flag is switched to use B.

H5. Using direct memory access (DMA), customer data is provided to theCache segments, and the NVS “virtual track buffer” 0 is provided to thesegments 0 and 1.

H6. Host adapter sends mail to Cache to commit data and sends mail toNVS with track buffer number used to commit data.

H7. Give device end to host indicating write complete. NVS will commitdata even after power loss.

N8. NVS sees mail, waits for Track NVSCB control block and “B” segments(if not there), then commits data by building NVS control block fortrack using NVS segments 0 and 1. The “Use A or B indicator” is switchedto “use B”.

N9. NVS sends “commit complete” mail to Cache.

C10. Cache sees complete mail from both adapter and NVS.

C11. Cache update control block with segments and sectors written inboth Cache/NVS and frees NVS track buffer.

C12. Cache sends write complete message to host adapter.

Note: The steps C5, H5 and H6 generally occur asynchronously. The NVSonly knows that it has something to commit when it sees the host adaptermail. The NVS must wait for step C5 to occur to know which segments touse next time.

FIG. 4 illustrates cache control blocks for tracks, and thecorresponding cache customer segments, which are seen by the hostadapters. The control blocks 400, e.g., control 0, control 1, . . . ,control n-1, control n, have a 1:1 relationship with the customersegments 450, e.g., segment 0, segment 1, . . . , segment n-1, segmentn.

FIG. 5 illustrates track NVS control blocks and the corresponding trackbuffers seen by the host adapters and real contiguous memory. The trackNVS control blocks 500, e.g., 0, 1, 2, . . . , x, have a 1:1relationship with the track buffers 550, which are seen by the hostadapters and real contiguous memory, e.g., 0, 1, 2, . . . , x.

FIG. 6 illustrates NVS control blocks for tracks, and the correspondingNVS customer segments not seen by the host adapters. The NVS controlblocks 600, e.g., control 0, control 1, . . . , control n-1, control n,have a 1:1 relationship with the NVS customer segments 650, e.g.,segment 0, segment 1, . . . , segment n-1, segment n.

FIG. 7 illustrates a cache control block data structure 700. The datastructure 700 includes a Track Identifier 710, such as device, cylinderand head. Generally, the disk tracks in a storage server may beidentified, e.g., by device, cylinder, and head. The device can be adisk drive in the disk arrays 160 (FIG. 1), while the cylinder may be aunit of storage with a fixed number of tracks, e.g., fifteen tracks, ona disk. Typically, there are thousands of cylinders in a device. Thehead is the read/write head on a disk drive. Any appropriate identifiermay be used. For example, the identifier of the device may be a serialnumber, while the identifiers of the cylinder and head may be based ontheir locations, e.g., cylinder 1, 2, 3, . . . , head 1, 2, 3, . . . .Flags 720, such as in use, modified and valid describe the correspondingcustomer data.

LRU/MRU Pointers 730 relate to a least recently used (LRU)/most recentlyused (MRU) list for track images. Each track image is associated with atrack in the disk arrays. For write data, e.g., modified data, the trackimage is associated with a track in the disk arrays 160 at which theassociated cache data is to be written. For read data, the track imageis associated with a track in the disk arrays 160 from which theassociated cache data was read. Each track image may comprise the amountof data that can be stored in one revolution of a disk in the diskarrays 160, e.g., 60 kB.

The data structure 700 further includes a list of Cache segments fortrack 740, a list of current NVS segments for track 750, a list of newNVS segments for track 755, a resident sector bit map 760, whichincludes both read and write data, a modified sector bit map 770, whichincludes only write data contained in NVS, and a copy of the modifiedsector bit map when a new write begins 775.

FIG. 8 illustrates an NVS control block data structure 800, whichincludes a Track Identifier 810, such as device, cylinder and head,flags 820, such as in use, modified and valid, an indicator indicatingwhether to use the A or B segments 845, a list of NVS segments for track850, which includes only previously used segments, and a modified sectorbit map 860 of previously used NVS segments according to the cachecontrol block 700.

FIG. 9 illustrates track buffer control blocks 900 and the correspondingvirtual track buffers 950 seen by the host adapters, but not thecontiguous memory. The virtual track buffers 950 contain real customersegments. The track buffer control blocks 900 have a 1:1 relationshipwith the virtual track buffers 950. For example, track buffer controlblocks 900 may indicate the “A” segments (entry 902), the track NVSCB(NVS control block-entry 904), the “B” segments (entry 906), and the“Use A or B” segments indicator (entry 908). Furthermore, the NVScontrol blocks for tracks have a 1:1 relationship with the NVS customersegments, which are seen by the host adapters, in the manner indicatedby FIG. 4.

FIG. 10 illustrates a virtual track buffer data structure. The datastructure 900 of FIG. 9 is illustrated in further detail. The “A”segments entry 902 provides a list of real NVS segments used for a writeto the track buffer. The Track NVSCB entry 904 shows the cache a view ofthe track in NVS. The “B” Segments entry 906 provide a list of real NVSsegments used for a write to the track buffer. The “Use A or B segments”indicator entry 908 indicates which list or set of segments were usedfor the write from the host adapter. During initialization, the cachecode will allocate real NVS segments for each “virtual track buffer”,initialize the “A” segment list 902, and set the “Use A or B indicator”908 to “Use A”. The entire data structure is then sent to the NVS beforeany host adapter writes are allowed. If we take a simple case of two“virtual track buffers” and each customer track can be held in two NVSsegments, the structure of FIG. 11 will result. However, othervariations are possible.

FIG. 11 illustrates an example of the virtual track buffer datastructure. A first track buffer, track buffer 0 (1100), includes entries1102, 1104, 1106 and 1108. Entry 1102 indicates that segments 0 and 1are the real NVS “A” segments used for a write to the track buffer.Entry 1104 indicates the track NVS control block at initial value. Entry1106 is uninitialized. Entry 1108 indicates that the “A” segments shouldbe used. A second track buffer, track buffer 1 (1110), includes entries1112, 1114, 1116 and 1118. Entry 1112 indicates that segments 2 and 3are the real NVS “A” segments used for a write to the track buffer.Entry 1114 indicates the track NVSCB at initial value. Entry 1116 isuninitialized. Entry 1118 indicates that the “A” segments should beused.

After the first write operation, the virtual track buffer structure ofFIG. 12 will result. After the first write has completed to segments 0and 1 (block 1102 in FIG. 11), segments 0 and 1 are no longer part ofthe virtual track buffer, but contain customer data. Block 1102 in FIG.12 therefore indicates the space occupied by segments 0 and 1 is nowuninitialized. Furthermore, entry 1106 is changed to indicate thatsegments 4 and 5 are the “B” segments, and entry 1108 is changed toindicate that the “B” segments should be used for writing additionaldata. Thus, the next time the track buffer 0 is used, the data will besent to NVS segments 4 and 5, and new segments will be sent into the “A”segment list. The entries 1112, 1114, 1116 and 1118 for the track buffer1 (1110) are unchanged.

An update write scenario to the same track can be provided as follows.Steps 1 and 2 are the same as steps H1 and H2 as discussed in connectionwith FIG. 3. In Step C3, the cache will now allocate NVS segments 6 and7. The cache will allocate track buffer 1, and move segments 6 and 7from the cache control block to “B” segments, and move segments 2 and 3to the cache control block. Cache steps C4 and C5 use track buffer 1.Host adapter step H5 uses buffer 1 and segments 2 and 3. NVS step N8changes as follows:

-   -   1. If the entire track was written again, then the NVS control        block for the track is updated to reflect that segments 2 and 3        have the data.    -   2. If either segment is completely written, then the NVS control        block for the track is updated to reflect the new segment.    -   3. If a segment is partially written, then the customer data in        the segment with the least amount of date is copied to the        segment with the most amount of data.

All other steps remain the same.

In the event of a power loss at the storage server 100 at NVS step N8,after the mail has landed in the NVS memory, and before the track buffercontrol block from cache step C5 has landed in the NVS memory, then thefollowing steps occur during the next power on:

-   -   1. NVS sends cache an NVS control block for each track within        NVS to allow cache to know which NVS segments are in use and        which segments are not in use.    -   2. NVS processes each commit mail message from above:    -   a. determine track id and virtual track buffer used form commit        mail message.    -   b. determine whether A or B segments were used for the write        from the virtual track buffer control block.    -   C. send mail message to cache indicating the exact NVS segments        to allocate for the track, knowing which segments were used for        the write before the power loss occurred, and indicating the        correct setting for the “Use A or B” indicator. The cache then        builds and sends a track buffer control block for the specified        track buffer to allow the commit operation to complete.    -   d. when the track buffer control block arrives, the NVS can then        commit the customer data.

NVS n-1 customer data protection can be provided as follows. A writeprocess from a host adapter to both cache and NVS can occur and proceedup to step H6. At any point, the host can abort out of the write. Ifhost adapter step H5 has occurred, then the n−1 version of the cachedata for the track has been overwritten (either partially or completely)with the new data that is no longer wanted. The n-1 version of the NVSdata for the track is still safe in the NVS segments, since the new datawas written to newly allocated NVS segments. The NVS can send the safen−1 data back to the cache to once again have two copies of the data.

FIG. 13 illustrates a method for allocating segments for each virtualtrack buffer. The flowchart shows the initialization of allocating the“A” segments for each virtual track buffer. An initialization processbegins at block 1300. When all track buffers have been initialized, theprocess is complete (block 1320). At block 1330, the first set ofsegments, termed “A” segments, are allocated, and a flag is set to usethe “A” segments for storing customer data (block 1340).

FIG. 14 illustrates a method for pre-allocating segments for a new writerequest. The flowchart shows new write request processing forpre-allocating a second set of segments when a write request occurs fora first set of segments, and shows the toggle between the “A” and “B”segments. When a new write request is received from a host adapter forwriting customer data (block 1400), and the flag in the track buffer(see FIGS. 11 and 12) is set to use the “A” segments, the “B” segmentsare allocated and sent to the NVS. The “B” segments are thuspre-allocated for storing additional data. At block 1430, the hostadapter writes the current customer data to the “A” segments. At block1440, the flag is set to use the “B” segments for the next writerequest, and the process ends at block 1480. If the flag is not set touse the “A” segments at block 1410, the “A” segments are allocated andsent to the NVS at block 1450. At block 1460, the host adapter writesthe current customer data to the “B” segments. At block 1470, the flagis set to use the “A” segments for the next write request, and theprocess ends at block 1480. The “A” segments are thus pre-allocated forstoring additional data. In this way, the use “A” or “B” segments flagis alternatingly set so that the first and second sets of segments arealternatingly selected for storing the customer data for which a writerequest has been made.

FIG. 15 illustrates a method for processing write requests following apower loss. Based on the use “A” or “B” segments flag, the NVS tells thecache which segments to allocate, and then commits the customer datathat resides in those segments. In particular, when the power comes backon following a power loss, at block 1500, it is determined whether allposted writes have been completed (block 1505). If this is true, theprocess ends at block 1510. If all posted writes have not beencompleted, and if the flag in the track buffer is set to use the “A”segments (block 1515), the NVS sends the “A” segments to cache (block1520). The “A” segments are allocated and sent to the NVS (block 1525),and the NVS commits the data in the “A” segments (block 1530). If theflag in the track buffer is not set to use the “A” segments (block1515), e.g., it is set to use the “B” segments or even other sets ofsegments, the NVS sends the “B” segments to cache (block 1535). The “B”segments are allocated and sent to the NVS (block 1540), and the NVScommits the data in the “B” segments (block 1545).

While the invention has been illustrated in terms of a dual clusterstorage server, it is applicable as well to multi-cluster systems havinghigher levels of redundancy as well as to single cluster systems.

The invention has been described herein with reference to particularexemplary embodiments. Certain alterations and modifications may beapparent to those skilled in the art, without departing from the scopeof the invention. The exemplary embodiments are meant to beillustrative, not limiting of the scope of the invention, which isdefined by the appended claims.

1. A method for storing customer data at a non-volatile storage (NVS) ata storage server, comprising: initializing the NVS, prior to receiving afirst write request at the storage server for writing first customerdata to the NVS, by allocating first segments in the NVS for storingdata; and in response to receiving the first write request, allocatingsecond segments in the NVS for storing second customer data.
 2. Themethod of claim 1, further comprising: receiving a second write requestat the storage server for writing the second customer data to the NVS;writing the second customer data to the second segments in the NVS; andin response to receiving the second write request, allocating thirdsegments in the NVS for storing third customer data.
 3. The method ofclaim 1, further comprising: maintaining a cache control block forallocating the first and second segments in the NVS.
 4. The method ofclaim 1, further comprising: maintaining a virtual track buffer forallocating the first and second segments in the NVS.
 5. The method ofclaim 1, wherein: the first write request is received at a cache at thestorage server from a host adapter at the storage server.
 6. The methodof claim 1, wherein: following commit processing of the first customerdata at the NVS, the NVS prepares to use the second segments to storethe second customer data for a subsequent write request.
 7. The methodof claim 1, further comprising: maintaining a virtual track bufferidentifying at least the first and second segments; and maintaining aflag identifying which of the at least first and second segments to usefor storing customer data for which a write request has been made. 8.The method of claim 7, further comprising: alternatingly setting theflag so that the at least first and second segments are alternatinglyselected for storing the customer data for which a write request hasbeen made.
 9. The method of claim 1, wherein customer data for which awrite request has been made is stored in the NVS in successive commitprocesses, the method further comprising: maintaining in the NVS, acrossa power loss, information identifying which of the first and secondsegments is involved in a current one of the successive commitprocesses.
 10. An apparatus for storing customer data at a non-volatilestorage (NVS) at a storage server, comprising: means for initializingthe NVS, prior to receiving a first write request at the storage serverfor writing first customer data to the NVS, by allocating first segmentsin the NVS for storing data; and means for allocating second segments inthe NVS, in response to receiving the first write request, for storingsecond customer data.
 11. The apparatus of claim 10, further comprising:means for receiving a second write request at the storage server forwriting the second customer data to the NVS; means for writing thesecond customer data to the second segments in the NVS; and means forallocating, in response to receiving the second write request, thirdsegments in the NVS for storing third customer data.
 12. The apparatusof claim 10, further comprising: means for maintaining a cache controlblock for allocating the first and second segments in the NVS.
 13. Theapparatus of claim 10, further comprising: means for maintaining avirtual track buffer for allocating the first and second segments in theNVS.
 14. The apparatus of claim 10, wherein: the first write request isreceived at a cache at the storage server from a host adapter at thestorage server.
 15. The apparatus of claim 10, wherein: following commitprocessing of the first customer data at the NVS, the NVS prepares touse the second segments to store the second customer data for asubsequent write request.
 16. The apparatus of claim 10, furthercomprising: means for maintaining a virtual track buffer identifying atleast the first and second segments; and means for maintaining a flagidentifying which of the at least first and second segments to use forstoring customer data for which a write request has been made.
 17. Theapparatus of claim 16, further comprising: means for alternatinglysetting the flag so that the at least first and second segments arealternatingly selected for storing the customer data for which a writerequest has been made.
 18. A program storage device, tangibly embodyinga program of instructions executable by a machine to perform a methodfor storing customer data at a non-volatile storage (NVS) at a storageserver, the method comprising the steps of: initializing the NVS, priorto receiving a first write request at the storage server for writingfirst customer data to the NVS, by allocating first segments in the NVSfor storing data; and in response to receiving the first write request,allocating second segments in the NVS for storing second customer data.19. The program storage device of claim 18, wherein the method furthercomprises: receiving a second write request at the storage server forwriting the second customer data to the NVS; writing the second customerdata to the second segments in the NVS; and in response to receiving thesecond write request, allocating third segments in the NVS for storingthird customer data.
 20. The program storage device of claim 18, whereinthe method further comprises: maintaining a cache control block forallocating the first and second segments in the NVS.
 21. The programstorage device of claim 18, wherein the method further comprises:maintaining a virtual track buffer for allocating the first and secondsegments in the NVS.
 22. The program storage device of claim 18,wherein: the first write request is received at a cache at the storageserver from a host adapter at the storage server.
 23. The programstorage device of claim 18, wherein: following commit processing of thefirst customer data at the NVS, the NVS prepares to use the secondsegments to store the second customer data for a subsequent writerequest.
 24. The program storage device of claim 18, wherein the methodfurther comprises: maintaining a virtual track buffer identifying atleast the first and second segments; and maintaining a flag identifyingwhich of the at least first and second segments to use for storingcustomer data for which a write request has been made.
 25. The programstorage device of claim 18, wherein the method further comprises:alternatingly setting the flag so that the at least first and secondsegments are alternatingly selected for storing the customer data forwhich a write request has been made.
 26. The method of claim 1, wherein:if a segment is partially written, customer data in a segment with theleast amount of data is copied to a segment with the most amount ofdata.